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Abstract.  A  controversial  issue  in  the  formal  methods  community  is 
the  degree  to  which  mathematical  sophistication  and  theorem  proving 
skills  should  be  needed  to  apply  a  formal  method.  A  fundamental  as¬ 
sumption  of  this  paper  is  that  formal  methods  research  has  produced 
several  classes  of  analysis  that  can  prove  useful  in  software  development. 
However,  to  be  useful  to  software  practitioners,  most  of  whom  lack  ad¬ 
vanced  mathematical  training  and  theorem  proving  skills,  current  formal 
methods  need  a  number  of  additional  attributes,  including  more  user- 
friendly  notations,  completely  automatic  (i.e. ,  pushbutton)  analysis,  and 
useful,  easy  to  understand  feedback.  Moreover,  formal  methods  need  to 
be  integrated  into  a  standard  development  process.  I  discuss  additional 
research  and  engineering  that  is  needed  to  make  the  current  set  of  formal 
methods  more  practical.  To  illustrate  the  ideas,  I  present  several  exam¬ 
ples,  many  taken  from  the  SCR  (Software  Cost  Reduction)  requirements 
method,  a  formal  method  that  software  developers  can  apply  without 
theorem  proving  skills,  knowledge  of  temporal  and  higher  order  logics, 
or  consultation  with  formal  methods  experts. 


1  Formal  Methods  in  Practice:  Current  Status 

During  the  last  decade,  researchers  have  proposed  numerous  formal  methods, 
such  as  model  checkers  [6]  and  mechanical  theorem  provers  [21],  for  developing 
computer  systems.  One  area  in  which  formal  methods  have  had  a  major  impact 
is  hardware  design.  Not  only  are  companies  such  as  Intel  beginning  to  use  model 
checking,  along  with  simulation,  as  a  standard  technique  for  detecting  errors  in 
hardware  designs,  in  addition,  some  companies  are  developing  their  own  in-house 
model  checkers.  Moreover,  a  number  of  model  checkers  customized  for  hardware 
design  have  become  available  commercially  [17]. 

Although  some  limited  progress  has  been  made  in  applying  formal  methods 
to  software,  the  use  of  formal  methods  in  practical  software  development  is  rare. 
A  significant  barrier  is  the  widespread  perception  among  software  developers 
that  formal  notations  and  formal  analysis  techniques  are  difficult  to  understand 
and  apply.  Moreover,  software  developers  often  express  serious  doubts  about  the 
scalability  and  cost-effectiveness  of  formal  methods. 

Another  reason  why  formal  methods  have  had  minimal  impact  is  the  absence 
in  practical  software  development  of  two  features  common  in  hardware  design 
environments.  First,  hardware  designers  routinely  use  one  of  a  small  group  of 
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languages,  e.g.,  Verilog  or  VHDL,  to  specify  their  designs.  In  contrast,  precise 
specification  and  design  languages  are  rarely  used  in  software  development. 

Second,  integrating  a  formal  method,  such  as  a  model  checker,  into  a  hard¬ 
ware  design  process  is  relatively  easy  because  other  tools,  such  as  simulators  and 
code  synthesis  tools,  are  already  a  standard  part  of  the  design  process  at  many 
hardware  companies.  In  contrast,  in  software  development,  no  standard  soft¬ 
ware  development  environments  exist.  (Although  “object-oriented  design”  has 
gained  considerable  popularity  in  recent  years,  this  process  is  still  largely  infor¬ 
mal  and  what  “object-oriented  design”  means  varies  considerably  from  one  site 
to  the  next.)  Moreover,  while  a  number  of  commercial  Computer-Aided  Software 
Engineering  (CASE)  tools  have  become  available  in  recent  years,  few  software 
developers  are  actually  using  the  tools  [18]. 

This  paper  distinguishes  light-weight  formal  methods  from  heavy-duty  meth¬ 
ods  and  then  describes  two  broad  classes  of  problems  in  which  formal  methods 
have  been  useful.  It  concludes  by  proposing  a  number  of  guidelines  for  making 
formal  methods  more  useful  in  practice. 

2  Light-Weight  vs.  Heavy-Duty  Techniques 

A  formal  analysis  technique  may  be  classified  as  either  “light-weight”  or  “heavy- 
duty”  .  The  user  of  a  light-weight  technique  does  not  require  advanced  math¬ 
ematical  training  and  theorem  proving  skills.  One  example  of  a  light-weight 
technique  is  an  automated  consistency  checker,  which  checks  a  specification  for 
syntax  and  type  errors,  missing  cases,  instances  of  nondeterminism,  and  circular 
definitions  (see,  e.g.,  [11,  10]).  In  contrast,  the  user  of  a  heavy-duty  technique 
must  be  mathematically  mature,  a  person  skilled  in  the  formulation  of  formal 
arguments  and  clever  proof  strategies.  The  most  common  heavy-weight  tech¬ 
niques  are  mechanical  theorem  provers,  such  as  PVS  [21]  and  ACL2  [16].  Other 
techniques  which  may  be  classified  as  heavy-duty  are  those  that  automatically 
generate  state  invariants  from  specifications  (e.g.,  see  [15,  3]).  Such  state  invari¬ 
ants  can  be  presented  to  system  users  for  validation  or,  alternately,  can  be  used 
as  auxiliary  invariants  in  proving  new  properties  from  the  specifications. 

Model  checkers  fall  somewhere  between  light-weight  and  heavy-duty  tech¬ 
niques.  Once  the  user  has  defined  the  state  machine  model  and  the  property 
of  interest,  the  model  checker  determines  automatically  whether  the  property  is 
satisfied.  One  problem  with  most  current  model  checkers  is  that  the  languages 
available  for  representing  the  state  machine  model  and  the  properties  of  inter¬ 
est  can  be  difficult  to  learn.  Usually,  model  checkers  require  the  representation 
of  a  property  is  some  form  of  temporal  logic.  Expressing  certain  properties  in 
temporal  logic  is  complex  and  error-prone,  not  only  for  practitioners  but  for  for¬ 
mal  methods  experts  as  well.  An  additional  problem  with  many  current  model 
checkers  is  that  sometimes  the  counterexample  produced  by  model  checking  is 
thousands  of  states  long  and  extremely  difficult  to  understand  (see,  e.g.,  [25]). 

Fortunately,  many  of  the  current  problems  with  model  checkers  are  not  in¬ 
herent  in  the  technology  but  simply  limitations  of  the  current  implementations. 


In  Section  4,  I  suggest  some  improvements  to  model  checkers,  which  should  make 
them  easier  to  use,  more  automatic,  and  hence  more  light-weight.  I  also  suggest 
how  automated,  mathematically  sound  abstraction  methods,  a  topic  of  current 
research,  can  help  make  model  checking  more  accessible  to  practitioners. 


3  Where  Have  Formal  Methods  Been  Applied? 

We  can  identify  two  large  classes  of  problems  where  formal  methods  have  had 
utility.  First,  formal  methods  have  been  used  to  formalize,  debug,  and  prove  the 
correctness  of  algorithms  and  protocols.  Using  formal  methods  to  tackle  such 
problems  has  proven  useful  in  both  hardware  and  software  applications:  once 
its  correctness  has  been  shown  formally,  the  algorithm  (or  protocol)  may  be 
used  with  high  confidence  in  many  applications.  While  model  checking  has  been 
used  to  analyze  various  protocols,  such  as  cache  coherence  protocols  and  security 
protocols  (see,  e.g.,  [20]),  the  deep  mathematical  reasoning  needed  to  verify  most 
algorithms  usually  requires  a  heavy-duty  theorem  prover. 

For  example,  recently,  a  microprocessor  manufacturer,  Advanced  Micro  De¬ 
vices  (AMD),  developed  a  new  algorithm  for  floating  point  division  on  the 
AMD586,  a  new  Pentium-class  microprocessor.  To  increase  confidence  in  the 
algorithm’s  correctness,  AMD  hired  a  team  of  formal  methods  experts  to  verify 
the  AMD586  microcode  that  implemented  floating  point  division.  The  experts 
used  ACL2,  an  extended  version  of  the  Boyer-Moore  theorem  prover,  to  formal¬ 
ize  the  algorithm  and  to  check  a  relatively  deep  mathematical  proof  [16].  After 
nine  weeks,  the  verification  effort  was  successfully  completed.  Hiring  the  formal 
methods  experts  to  construct  the  formal  proof  and  mechanically  check  it  using 
ACL2  was  a  relatively  cheap  means  for  AMD  to  gain  confidence  in  the  AMD586 
microcode  for  floating  point  division.  Moreover,  AMD  can  confidently  reuse  the 
algorithm  in  future  microprocessors. 

In  a  second  class  of  problems,  formal  methods  are  used  to  demonstrate  that 
a  specification  of  a  system  (or  system  part)  satisfies  certain  properties,  or  that 
a  detailed  description,  such  as  a  design  or  an  implementation,  of  a  system  sat¬ 
isfies  a  given  specification.  In  this  latter  case,  the  theorems  proven  have  been 
referred  to  as  “junk”  theorems,  since  unlike  theorems  proven  about  algorithms 
and  protocols,  these  theorems  are  not  usually  of  interest  outside  the  system  that 
is  being  analyzed. 

Experience  applying  formal  methods  to  the  requirements  specifications  of 
TCAS  II  [10],  a  collision  avoidance  system  for  commercial  aircraft,  and  WCP 
[14],  a  safety-critical  component  of  a  U.S.  military  system,  illustrates  this  sec¬ 
ond  class  of  problems.  In  each  case,  the  specification  was  analyzed  for  selected 
properties  using  both  consistency  checking  and  model  checking.  In  both  cases, 
the  analysis  exposed  significant  errors  [10,  1,  14].  The  properties  analyzed  in¬ 
cluded  both  application-independent  properties  (e.g.,  a  given  function  is  total) 
and  application-dependent  properties.  In  each  case,  the  properties  and  their 
proofs  were  of  little  interest  outside  the  analyzed  systems. 


The  analysis  of  such  specifications  does  not  normally  require  deep  reason¬ 
ing.  Hence,  more  light-weight  methods,  such  as  consistency  checking  and  model 
checking,  are  more  cost-effective  than  heavy-duty  theorem  proving.  Yet,  the  anal¬ 
yses  performed  were  often  quite  complex,  especially  for  model  checking,  due 
to  the  enormous  size  of  the  state  space  that  needed  to  be  analyzed.  Further, 
the  presence  in  the  specifications  of  logical  expressions  containing  a  mixture  of 
boolean,  enumerated  types,  integers,  and  reals  as  well  as  arithmetic  and  func¬ 
tions  made  automated  consistency  checking  difficult,  especially  in  the  TCAS  II 
specification.  Two  potential  solutions  to  these  problems,  both  of  which  are  top¬ 
ics  of  current  research,  are  automated  abstraction  methods  and  more  powerful 
decision  procedures. 

4  Guidelines  for  Producing  a  Practical  Formal  Method 

Presented  below  are  a  number  of  guidelines  for  making  formal  methods  more 
practical.  The  objective  of  these  guidelines  is  to  make  formal  methods  light¬ 
weight  and  thus  more  accessible  to  software  developers.  To  a  large  extent,  ap¬ 
plying  these  guidelines  is  simply  good  engineering  practice.  However,  in  other 
cases,  additional  research  is  needed. 


4.1  Minimize  Effort  and  Expertise  Needed  to  Apply  the  Method 

To  be  useful  in  practice,  formal  methods  must  be  convenient  and  easy  to  use. 
Most  current  software  developers  are  reluctant  to  use  current  formal  methods 
because  they  find  the  learning  curve  too  steep  and  the  effort  required  to  apply 
a  formal  method  too  great.  In  many  cases,  deciding  not  to  use  a  formal  method 
is  rational.  The  time  and  effort  required  to  learn  about  and  apply  a  formal 
method  may  not  be  worth  the  information  and  insight  provided  by  the  method; 
in  some  cases,  the  effort  could  be  better  spent  applying  another  method,  such 
as  simulation.  Suggested  below  are  three  ways  in  which  the  difficulty  of  learning 
and  applying  a  formal  method  can  be  reduced. 


Offer  a  language  that  software  developers  find  easy  to  use  and  easy 
to  understand.  The  specification  language  must  be  “natural” ;  to  the  extent 
feasible,  a  language  syntax  and  semantics  familiar  to  the  software  practitioner 
should  be  supported.  The  language  must  also  have  an  explicitly  defined  formal 
semantics  and  it  should  scale.  Specifications  in  this  language  should  be  auto¬ 
matically  translated  into  the  language  of  a  model  checker  or  even  a  mechanical 
theorem  prover. 

Our  group  and  others  (see,  e.g.,  [14,  22,  7])  have  had  moderate  success  with  a 
tabular  notation  for  representing  the  required  system  behavior.  Underlying  this 
notation  is  a  formal  state-machine  semantics  [11].  Others,  such  as  Heimdahl  and 
Leveson  [10],  have  proposed  a  hybrid  notation,  inspired  by  Statecharts  [9],  that 
combines  tables  and  graphics;  this  notation  also  has  a  state-machine  semantics. 


Specifications  based  on  tables  are  easy  to  understand  and  easy  for  software 
practitioners  to  produce.  In  addition,  tables  provide  a  precise,  unambiguous  basis 
for  communication  among  practitioners.  They  also  provide  a  natural  organiza¬ 
tion  which  permits  independent  construction,  review,  modification,  and  analysis 
of  smaller  parts  of  a  large  specification.  Finally,  tabular  notations  scale.  Evidence 
of  the  scalability  of  tabular  specifications  has  been  shown  by  Lockheed  engineers, 
who  used  a  tabular  notation  to  specify  the  complete  requirements  of  the  C-130J 
Flight  Program,  a  program  containing  over  230K  lines  of  Ada  code  [8]. 

In  addition  to  tabular  notations,  other  user-friendly  notations  should  also 
be  explored.  For  example,  one  group  is  developing  a  set  of  tools  which  ana¬ 
lyze  message  sequence  charts,  a  notation  commonly  used  in  communication  pro¬ 
tocols  [24].  Others  are  exploring  a  front-end  for  model  checking  based  on  the 
graphical  notation  Statecharts. 


Make  Formal  Analysis  as  Automatic  as  Possible.  To  the  extent  feasible, 
analysis  should  be  “pushbutton” .  One  formal  technique  that  is  already  largely 
pushbutton  is  automated  consistency  checking.  To  achieve  this  automation,  con¬ 
sistency  checking  is  implemented  by  efficient  decision  procedures,  such  as  seman¬ 
tic  tableaux  [11]  and  BDDs  (Binary  Decision  Diagrams)  [10].  Moreover,  a  recent 
paper  [23]  shows  how  the  Stanford  Validity  Checker  (SVC),  which  uses  a  deci¬ 
sion  procedure  for  a  subset  of  first-order  logic  with  linear  arithmetic,  can  check 
the  validity  of  expressions  containing  linear  arithmetic,  inequalities,  and  unin¬ 
terpreted  function  symbols. 

More  progress  is  needed,  however.  Specifications  of  many  safety-critical  ap¬ 
plications  contain  logical  expressions  that  mix  booleans,  enumerated  types,  inte¬ 
gers,  and  reals.  How  to  analyze  such  mixed  expressions  efficiently  is  an  unsolved 
problem.  New  research  is  needed  that  shows  how  various  decision  procedures, 
such  as  term  rewriting,  BDDs,  and  constraint  solvers,  can  be  combined  to  check 
the  validity  of  such  expressions. 

Another  area  where  more  automation  is  needed  is  model  checking.  Before 
practical  software  specifications  can  be  model  checked  efficiently,  the  state  explo¬ 
sion  problem  must  be  addressed — i.e. ,  the  size  of  the  state  space  to  be  analyzed 
must  be  reduced.  An  effective  way  to  reduce  state  explosion  is  to  apply  abstrac¬ 
tion.  Unfortunately,  the  most  common  approach  is  to  develop  the  abstraction 
in  ad  hoc  ways — the  correspondence  between  the  abstraction  and  the  original 
specification  is  based  on  informal,  intuitive  arguments.  Needed  are  mathemati¬ 
cally  sound  abstractions  that  can  be  constructed  automatically.  Recent  progress 
in  automatically  constructing  sound  abstractions  has  been  reported  in  [4,  5]. 


Provide  Good  Feedback.  When  formal  analysis  exposes  an  error,  the  user 
should  be  provided  with  easy-to-understand  feedback  useful  in  correcting  the 
error.  Techniques  for  achieving  this  in  consistency  checking  already  exist  (see, 
e.g.,  [12,  23]).  As  noted  above,  counterexamples  produced  by  model  checkers 
require  improvement.  One  promising  approach,  already  common  in  hardware 
design,  uses  a  simulator  to  demonstrate  and  validate  the  counterexample. 


4.2  Provide  a  Suite  of  Analysis  Tools 


Because  different  tools  detect  different  classes  of  errors,  users  should  have  avail¬ 
able  an  entire  suite  of  tools.  This  suite  may  include  a  consistency  checker,  a 
simulator,  a  model  checker,  as  well  as  a  mechanical  theorem  prover  [13].  The 
tools  should  be  carefully  integrated  to  work  together.  This  is  already  happen¬ 
ing  in  hardware  design,  where  simulators,  model  checkers,  equivalence  checkers, 
and  code  synthesis  tools  are  being  used  in  complementary  ways;  moreover,  some 
progress  has  been  made  in  making  tools,  such  as  model  checkers  and  simulators, 
work  together  [17].  One  benefit  of  having  a  suite  of  tools  is  that  properties  that 
have  been  shown  to  hold  using  one  tool  may  simplify  the  analysis  performed 
with  a  second  tool.  For  example,  validating  that  each  function  in  a  specification 
is  total  can  simplify  subsequent  verification  using  a  mechanical  prover. 


4.3  Integrate  the  Method  into  the  User’s  Development  Process 

To  the  extent  feasible,  formal  methods  should  be  integrated  into  the  existing 
user  design  process.  Techniques  for  exploiting  formal  methods  in  object-oriented 
software  design  and  in  software  development  processes  which  use  semiformal 
languages,  such  as  Statecharts,  should  also  be  explored.  How  formal  methods 
can  be  integrated  into  the  user’s  design  process  should  be  described  explicitly. 


4.4  Provide  a  Powerful,  Customizable  Simulation  Capability 

Many  formal  methods  researchers  underestimate  the  value  of  simulation  in  ex¬ 
posing  defects  in  specifications.  By  symbolically  executing  the  system  based  on 
the  formal  specification,  the  user  can  ensure  that  the  behavior  specified  satisfies 
his  intent.  Thus,  unlike  consistency  checking,  model  checking,  and  mechanical 
theorem  proving,  which  formally  check  the  specification  for  properties  of  interest, 
simulation  provides  a  means  of  validating  a  specification.  In  running  scenarios 
through  the  simulator,  the  user  can  also  use  the  simulator  to  check  properties 
of  interest.  Another  use  of  simulation  is  in  conjunction  with  model  checking;  as 
suggested  above,  simulation  can  be  used  to  demonstrate  and  validate  counterex¬ 
amples  obtained  from  a  model  checker. 

One  important  approach  to  selling  formal  methods  is  to  build  customized 
simulator  front-ends,  tailored  to  particular  application  domains.  For  example, 
we  have  developed  a  customized  simulator  front-end  for  pilots  to  use  in  evaluat¬ 
ing  an  attack  aircraft  specification.  Rather  than  clicking  on  monitored  variable 
names,  entering  values  for  them,  and  seeing  the  results  of  simulation  presented 
as  variable  values,  a  pilot  clicks  on  visual  representations  of  cockpit  controls 
and  sees  results  presented  on  a  simulated  cockpit  display.  This  front-end  allows 
the  pilot  to  move  out  of  the  world  of  the  specification  and  into  the  world  of 
attack  aircraft,  where  he  is  the  expert.  Such  an  interface  facilitates  evaluation  of 
the  specification.  Using  a  commercially  available  GUI  (Graphical  User  Interface) 
Builder,  one  can  construct  a  fancy  simulator  front-end  in  a  few  days. 


5  More  “Usable”  Mechanical  Theorem  Provers 


Although  mechanical  theorem  provers  have  been  used  by  researchers  to  verify 
various  algorithms  and  protocols,  they  are  rarely  used  in  practical  software  de¬ 
velopment.  For  provers  to  be  used  more  widely,  a  number  of  barriers  need  to 
be  overcome.  First,  the  specification  languages  provided  by  the  provers  must 
be  more  natural.  Second,  the  reasoning  steps  supported  by  a  prover  should  be 
closer  to  the  steps  produced  in  a  hand  proof;  current  provers  support  reasoning 
steps  that  are  at  too  low  and  detailed  a  level.  One  approach  to  this  problem  is  to 
build  a  prover  front-end  that  is  designed  to  support  specification  and  proofs  of  a 
special  class  of  mathematical  models.  An  example  of  such  a  front-end  is  TAME, 
a  “natural”  user  interface  to  PVS  that  is  designed  to  specify  and  prove  proper¬ 
ties  about  automata  models  [2].  Although  using  a  mechanical  provers  will  still 
require  mathematical  maturity  and  theorem  proving  skills,  making  the  prover 
more  “natural”  and  convenient  to  use  should  encourage  more  widespread  usage. 


6  Conclusions 

It  is  my  belief  that  software  practitioners  who  are  not  formal  methods  experts 
can  benefit  from  formal  methods  research.  However,  to  do  so,  they  need  formal 
methods  that  are  user-friendly,  robust,  and  powerful.  To  enjoy  the  benefits  of 
formal  methods,  a  user  does  not  need  to  be  mathematically  sophisticated  nor 
need  he  be  capable  of  proving  deep  theorems.  One  analogy  that  I  heard  at  CAV 
’98  is  that  beautiful  music  can  come  from  either  a  good  violin  or  a  highly  talented 
violinist.  Light-weight  techniques  offer  software  developers  good  violins.  A  user 
need  not  be  a  talented  violinist  to  benefit.  This  is  in  contrast  to  heavy-duty 
techniques  where  the  user  needs  to  be  a  good  violinist. 

Formal  methods  research  has  already  produced  a  significant  body  of  theory. 
Moreover,  some  promising  research  is  currently  in  progress  in  automated  ab¬ 
straction  and  automatic  generation  of  invariants  (e.g.,  [19,  4,  15,  5]).  However, 
to  make  formal  methods  practical,  good  engineering  is  needed.  The  user  of  for¬ 
mal  methods  should  not  need  to  communicate  the  required  system  behavior  in 
some  arcane  language  nor  to  decipher  the  meaning  of  obscure  feedback  from  an 
analysis  tool.  What  a  practical  formal  method  should  do  is  liberate  the  user  to 
tackle  the  hard  problems  that  humans  are  good  at  solving,  e.g., 

—  What  exactly  is  the  required  system  behavior? 

—  What  are  the  critical  system  properties? 

—  How  can  I  make  the  specification  easy  for  others  to  understand? 

—  What  are  the  likely  changes  to  the  specification  and  how  can  I  organize  the 
specification  to  facilitate  those  changes? 

—  What  should  the  missing  behavior  be?  How  can  this  nondeterminism  be 
eliminated?  How  do  I  change  the  specification  to  avoid  this  property  viola¬ 
tion? 
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